Skip to content

Fix flaky open-connect-content e2e test#3677

Draft
zackverham wants to merge 8 commits intomainfrom
fix-open-connect-content-flaky-test
Draft

Fix flaky open-connect-content e2e test#3677
zackverham wants to merge 8 commits intomainfrom
fix-open-connect-content-flaky-test

Conversation

@zackverham
Copy link
Collaborator

@zackverham zackverham commented Mar 9, 2026

Summary

Fixes the flaky open-connect-content e2e test that was failing across multiple Connect versions (preview, release, 2023.03.0, 2025.03.0).

Root cause

The ConnectContentFileSystemProvider was blocking VS Code's workspace validation during the workspace switch. When updateWorkspaceFolders is called, code-server validates the new folder by calling stat() and readDirectory() on the root URI. Our implementation awaited the full bundle fetch pipeline (Go backend startup → credential refresh → Connect API call → tar extraction) before responding. This caused code-server to silently reject the workspace change because the validation timed out.

Additionally, in code-server, updateWorkspaceFolders creates a multi-root workspace where the content folder appears at aria-level="2" instead of aria-level="1", so the test's CSS selector was missing the GUID entirely.

Extension fixes (connect_content_fs.ts)

  • Non-blocking stat() for root URIs: Returns an immediate directory entry without waiting for the bundle fetch. The bundle is kicked off in the background.
  • Non-blocking readDirectory() for root URIs: Returns whatever is cached (or [] if nothing yet), then fires a FileChangeType.Changed event when the bundle fetch completes to trigger VS Code to refresh the explorer tree.
  • Non-blocking error handling: showErrorMessage and the credential dialog are fire-and-forget (void) instead of awaited, so they don't stall the filesystem provider.

Test fixes (open-connect-content.cy.js)

  • Removed aria-level='1' restriction from the GUID selector — matches the folder at any tree depth to handle both single-folder and multi-root workspace modes.
  • Added notification toast dismissal during polling.
  • Increased waitUntil timeout to 120s.
  • Added explorer DOM diagnostics to the error message for easier debugging of future failures.

Test plan

  • All 4 e2e matrix variants pass (preview, release, 2023.03.0, 2025.03.0)
  • Unit tests pass (18/18) including new error-handling coverage
  • Lint and formatting clean

🤖 Generated with Claude Code

zackverham and others added 8 commits March 9, 2026 17:18
Replace URL change detection with direct explorer polling to handle
both workspace switch code paths (updateWorkspaceFolders and openFolder).
Consolidate 5 retryWithBackoff blocks into a single waitUntil loop with
try-catch for page reload safety.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The connect-content filesystem provider's stat() call was blocked by
awaited UI dialogs (showErrorMessage, credential flow), preventing the
explorer from rendering the workspace folder during e2e tests.

- Move cache population before error notification in fetchAndCacheBundle
- Fire-and-forget showErrorMessage and credential dialog instead of awaiting
- Increase e2e waitUntil timeout to 120s and dismiss notification toasts
- Add unit tests verifying stat/readDirectory resolve on fetch failure

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Screenshots show the workspace switch never happens on preview and
2023.03.0 - the URL stays at /?folder=/home/coder/workspace. Adding
cy.log diagnostics to capture: content record values, URL after command,
explorer state, notification messages, and quick input visibility during
the waitUntil polling loop.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The workspace switch via updateWorkspaceFolders was silently failing
because code-server validates new workspace folders by calling stat()
on the root URI. The stat() call blocked on the bundle fetch (which
depends on Go backend readiness and Connect API), causing code-server
to reject the workspace change entirely.

Now stat() returns an immediate directory entry for root content URIs
(/{guid}) without waiting for the bundle. The bundle fetch is kicked
off in the background and the actual content loads lazily when
readDirectory() is called by the explorer.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
On Connect 2023.03.0, code-server was dropping the connect-content
workspace folder because readDirectory() blocked on the bundle fetch.
When the bundle takes too long (slow Connect API, Go backend startup),
code-server rejects the workspace change.

Now readDirectory() returns an empty list immediately for root URIs if
the bundle hasn't been cached yet, and fires a FileChangeType.Changed
event when the fetch completes to trigger VS Code to refresh the tree.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
In multi-root workspace mode (triggered by updateWorkspaceFolders in
code-server), the workspace name appears at aria-level 1 and the
connect-content folder drops to aria-level 2. The previous selector
only checked level 1, missing the GUID folder entirely.

Now the test searches for the GUID anywhere in the explorer tree
regardless of nesting level.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Include the actual explorer row contents (text + aria-level) in the
failure error message so we can see exactly what the DOM contains
when the GUID selector doesn't match.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
// The actual bundle is fetched lazily when readDirectory() is called.
if (isRootContentUri(uri)) {
// Kick off the bundle fetch in the background so readDirectory() is faster
void this.ensureBundleForUri(uri);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what does void do here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

claude is indicating that this is to avoid linting errors because this is an asynchronous promise that we are explicitly not awaiting on.

https://typescript-eslint.io/rules/no-floating-promises/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants